The code looks good, but how will a dev know what to use instead of these deprecated helpers? Is there anyway we could add a link inside the message?

That's a great call.

I'll build a wiki page and have _deprecated link to it.

1.4.0 is already out there and in use. Shouldn't the deprecation be after 1.5.x based on two releases of warning (since .1.4.x is already out there without it)

Less sure about @idx. People have proposed a parameter that would support a base value other than 0 which is really useful for some applications.

Linking to #95

My thought on an idx that doesn't start from 0 is just to use {@math} to do what you need; since it's now a variable instead of a helper it can be used as a param.

Deprecation wiki page: https://github.com/linkedin/dustjs-helpers/wiki/Deprecated-Features

See #80 for an option to have @idx start with an offset

👎 we should probaly keep idx

I don't super see the benefit of {@idx offset="4"/} vs {@math key="{$idx}" method="add" operand="4"/} but I am not nearly invested enough to mind not deprecating it 😛

Mostly it's just the Python principle of "there should be only one-- preferably obvious-- way to do it".

So take out the deprecation of {@idx} ?

Re: deprecation version, should a feature have to be deprecated in x.x.0 to be removed in x.x+1.0? I think that might be too slow, but I'm not hard-set.

No, you're right-- because we need to have a feature available for the entire life of any version of dust supported by that version of the helpers.

So since 1.4.x supports up to Dust 2.5, we can't remove the feature until 1.6 which supports Dust 2.6 and 2.7.

I think I'll add a target param to _deprecate.

Yeh, the @ idx way is just more concise but I could live with @ math only way of doing it. As they are both helpers, they have the same general limitations as to where they can be used.

I know this is way late, but I wanted to let you know of a combination of bad things caused by this PR :(

At least, with the version of dust that was active at this time, the log level defaulted to NONE, so the deprecation warning wasn't shown by default. Then, when the package was updated to a version after @if had been removed, it failed to function silently. Finally, this change happened with a minor version update, which means npm install will simply break a site when it shouldn't, with no warning (by default) before and no useful error afterwards.

This was a really bad experience, and I hope the procedure is different now and in the future :\